Subject: Frame-Relay Formats for HPR

From: "jim (j.) cobban" <[email-masked]>
Date: Wed, 8 Mar 1995 16:53:00 -0500

In my previous note I wrote:

>It is my belief that the proposed encapsulation for HPR over Frame-Relay is
>unworkable in practice.  The encapsulation was proposed under the apparent
>misunderstanding that there would never be more than one HPR connection over
>a given Frame-Relay virtual circuit.  Considering that Frame-Relay is popular
>as a connection between gateway or router boxes which act on behalf of
>multiple down-stream stations, this is not a supportable conclusion.
>Therefore the Frame-Relay encapsulation for HPR must have a data link layer
>which provides the multiplexing functionality of 802.2 LLC.
>
...
>
>The requirement to support multiplexing of multiple link connections between
>a single pair of stations, whether on Frame-Relay or natively on a LAN,
>causes problems for the proposal in section 6.2.2, to use a separate SAP for
>HPR traffic in order to bypass the error checking.  I would like to see
>discussion of how that would be implemented in the case of gateways which may
>already be using all of the valid SAPs just to carry normal traffic.  Even if
>there are TWO saps in use, how do they resolve the conflict over the use of
>X'C8'?  Is it really that much more work to check for a UI than to check for
>a special SAP?  Could IBM present actual performance measurements of the two
>implementation choices to demonstrate that this complication is justified?

I wish to focus for a moment on the impact which the HPR draft
encapsulation of HPR over LANs and Frame-Relay will have on existing LLC
layer gateways.  An LLC layer gateway includes FRADs and the popular SDLC to
LLC2 gateways.  These boxes characteristically operate in the gap between
bridges and routers to deal with problems of media incompatibility and LLC2
timing problems.  In this way they are similar to DLSw, but unlike DLSw they
act like routers in that they process traffic addressed to a specific local
MAC address rather than "bridging" to a virtual ring and servicing the
"actual" remote MAC addresses.  In order to support multiple remote link
stations they use multiple SAPs.  In most cases they also locally terminate
LLC2, although some FRADs pass LLC2 transparently through.

These are the boxes which have problems with the proposed HPR encapsulation
in which a separate SAP is used to quickly identify traffic as HPR.  This
technique, rather than using UI frames on the same SAP pair is proposed
because of the design of the 6611.  I am informed that on the 6611 it would
take 50 additional instructions to recognize HPR frames using UI instead of
SAP.  However for an LLC2 gateway the first problem is that all of the SAPs
may already be used up, and the proposal would at the least divide the
number of available SAPs in half.  The second problem for these gateways is
that they would have to intercept the XID exchange, locate the HPR SAP CV
and modify it to point at the SAP.  By comparison if UI frames were used on
the same SAP pair many LLC2 gateways would require no modification, and
others would only require modification to support transporting UI frames.

IBM has raised the concern that they have already shipped the code support
for the proposal in the current version of the HPR draft.  Their position is
that this encapsulation (using a separate SAP on LANs and using a null layer
2 on Frame-Relay) must be endorsed because they have already shipped the
code.  Also all existing LLC layer gateways must be modified to recognize
and transport HPR.

I really sympathize with this concern, but I must ask the AIW in general to
comment on whether it is appropriate behavior for one member to ship
product code based upon an incomplete specification and then demand that
everyone else change their implementations to accomodate these premature
deliveries.  I certainly understood that as members of the AIW we were not
permitted to ship production implementations of any of these features until
CP was reached.